home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-07-20 | 3.4 KB | 81 lines | [TEXT/CWIE] |
- Resources in ACL:
-
- Resources are to be accessed through three means:
-
- Resource files (a collection of resources)
- Resources (a collection of references to data chunks)
- Resource Accessors (these are the data chunks)
-
- Since I'm basically putting more structure on a moderately structured content, I've got to
- decide how to represent these things in a vaguely structured way on disk.
-
- Resource files are obvious.
-
- There should only be a very loose binding between resources and what they access. A typical
- situation should look like:
-
- Build window:
- TBaseWindow::TBaseWindow( TResource res ) {
- TResource winResource= TResource( res, 'WnPR' );
- Rect *boundsRect= (Rect*)TContentGenerator::Build( TResource( winResource, 'rect', 0 ) );
- mWindow= ::NewWindow( boundsRect, &c, &c );
- delete boundsRect;
- mContent= (TLayoutLeaf*)TContentGenerator::Build( TResource( winResource, 'cont', 0 ) );
- }
- TBaseWindow *myWindow= new TBaseWindow( TResource( theResFile, 'AcWN', 128 ) );
-
- To register your own class to be built from a resource, the interface might look like
-
- class MContentGenerator
- {
- virtual void *BuildContent( TResource )=0;
- }
-
- class TMyGenerator:
- public MContentGenerator
- {
- virtual void *BuildContent( TResource );
- }
-
- void *TMyGenerator::BuildContent( TResource res )
- {
- return( (void*)new TMyKindOfLayout( res ) );
- }
-
- void Init() {
- //...Miscelanious initialization
- TContentGenerator::AddSubtypeGenerator( new TMyGenerator(), kConicContentTypeCode );
- //...other initialization
- }
-
- Some things should be obvious about my goals around now..
- First: Resources should be lightweight. They're thrown around the stack all the time, and I
- don't want that to incur that much overhead.
- Second: They're very abstract. Data is gotten from the resource through build functions about
- which we know nothing.
- Third: They can be referenced hierarchically. It's possible to get a reference to a resource
- via a containing resource.. Strictly speaking, the resource is not contained but is rather
- referenced, but the point is that it is a one step process to get a resource whose reference
- is contained in another one.
-
- That having been said, its probably time to describe the resource format.
-
- ACLs resources are the same as MacOS resources, with the following definition of their content:
- The content is full of 64-bit values, of which the first 32 describe a type and the meaning of
- the second 32 varies based on the value of the first. There are only two ways in which the
- first 32 bits can affect the interpretation of the second:
-
- If the first 32-bits are cleared, the second set is interpreted as an integer.
- For any other value of the first 32-bits, they are interpreted as a resource reference, and
- are interpreted as the type-code of the resource. The second 32-bits are then interpreted
- as the index of the referenced resource of this type.
-
- There also has to be some sort of way for certain resource items (such as menus) to find another
- instance of a resource item (such as the thing that will respond to the menu). This will be
- done in the same way that Apple Event Objects will be resolved.. Through some kind of selector.
- There will be two ways that the selector will work in the framework: index and string, both of
- which will be passed to an "Object Resolver" function.
-
- For example, the "Close" menu item would be stored in a resource that contained two data chunks..
- The string and the resolver. The resolver would reference 'AcWN' "Front" (for the frontmost
- window).